When generating test vectors that make use of an overflowing counter, I personally think it would be best to test at least 4 blocks of output. That way, if one of the backends has 32-bit counter addition on any of the 4 blocks generated in parallel, it will be caught. The 4-block test won't catch anything on chacha20 or rand_chacha, but it might catch a bug when/if we ever add a new backend for chacha20. For example, only testing with 3 blocks of output will not catch this bug, but testing 4 blocks will catch this bug:

    unsafe fn write_par_ks_blocks(&mut self, buffer: &mut [u32; 64]) {
        let mut blocks = [
            [self.state[0], self.state[1], self.state[2], self.state[3]],
            [
                self.state[0],
                self.state[1],
                self.state[2],
                add_counter!(self.state[3], self.ctrs[0], V), // correct addition
            ],
            [
                self.state[0],
                self.state[1],
                self.state[2],
                add_counter!(self.state[3], self.ctrs[1], V), // correct addition
            ],
            [
                self.state[0],
                self.state[1],
                self.state[2],
                vaddq_u32(self.state[3], self.ctrs[2]), // simple example of incorrect addition
            ],
        ];
    ...

While this mistake is unlikely to happen, it could happen and we might not have another test that will catch it. We would only need to increase the amount of blocks tested beyond 4 blocks in the future if we increased the results buffer size, which is pretty unlikely given that even with avx512, we would still be able to generate 4 blocks in parallel. But keep in mind that at the absolute minimum, 2 blocks need to be tested in order to actually observe the counter overflowing, but 4 blocks will test each block of the parallel-y generated blocks.

But I do notice that the current write_par_ks_blocks could be rewritten to use strictly 64 bit addition, but ideally the code would be condensed into a fn called rounds() that would use add_counter!() because any cipher or RNG could be able to use the rounds() fn

But I will add that you can still use only 2 blocks of expected output, but use different starting block_poses. For example, start at u32::MAX then check the first two blocks. Switch to u32::MAX - 1, then skip the first block and check the next 2 blocks, then switch to u32::MAX - 2 and skip the first two blocks and check the next 2 blocks. And that should cover all of the parblocks.

Thanks @nstilt1. I opted to test six blocks (one before wrap, four during, one after). I think this suffices?

Further note: these test vectors are not exactly in the right place! StdRng does not support setting the IV/stream. It does not support directly setting the counter, though obviously one could generate 2^32 + 1 blocks.

To be fair, the parblocks counter addition tests could probably only be ran in chacha20 given that there are multiple backends, where a new one could be added at any time (unless rand's CI/CD tests are going to use all of the backends. If rand CI/CD tests don't use all of the backends then the test only confirms that one of the backends is working properly). Whereas chacha20 will most likely test all backends it has implemented, since it needs to test them

I just tested it out by mutating the neon backend, and the counter_wrapping_64_bit_counter test will fail if the fourth PARBLOCK uses 32-bit addition, so I am unsure if an extra PARBLOCKS counter test is required... it probably isn't

Yes, these may be a little excessive here, but I don't see the harm in keeping them either (they're hardly slow and I'm not too fussed about the line count, though much more and it would have to be in a separate test).